1. Field of the Invention
The present invention generally relates to the transmission of packet data in a communications system, and more particularly to a system and method for sending packet data which includes header information.
2. Background of the Related Art
As mobile communications technology continues to evolve, wireless phone sets are expected to become more widely used than standard wired telephone sets. Wired sets, however, remain the terminal of choice for some applications. For example, radio mobile communications technology significantly lags behind the performance of existing wired communications systems when it comes to transmitting large amounts of data and voice traffic between terminals. Several wireless communications standards have been proposed to address this problem. One standard called IMT-2000 allows large amounts of data to be communicated between terminals and therefore has been promoted in many countries. In fact, international cooperation is currently underway for developing a single standard for this technology.
Recently, this cooperative effort has resulted in an initiative known as the third generation partnership project (3GPP). The 3 GPP initiative has been established for the purpose of standardizing, among other things, a third-generation IMT-2000 system based on a communications platform adopted in Europe. The standard, known as the universal mobile telecommunications system (UMTS), has received contributions from a variety of national, international, and local standardization institutions such as TTA in Korea, CWTS in China, T1 in the U.S.A., and ARIB/TTC in Japan.
The UMTS adopts a wideband code division multiple access (WCDMA) technique as a radio access network technique, and is being developed to include a general packet radio service (GPRS) based on a packet-switching network and a global system for a mobile communication (GSM) based on a circuit switching network. UMTS is also being developed to provide multimedia services such as voice, image and data.
The 3 GPP project includes five technical specification groups (TSG) each of which handles development, approval and management of the standard in a related field.
The radio access network (RAN) group (TSG-RAN) manages the development of functional requirements and a standard for an interface between wireless terminals and a UMTS terrestrial radio access network (UTRAN). The core network (CN) group (TSG-CN) manages the development of the functions of the core network, and the requirements and the standard of an interface which allows the UTRAN to access a circuit-switching backbone network or a packet-switching backbone network.
The full-header plays a critical role in the header compression technique of the related art packet-switching backbone network. If the full-header is not transmitted properly, every packet received thereafter cannot be decompressed and is discarded. In order to solve this problem when a non-TCP protocol such as UDP/IP is used, the related art system requires a transmitting party to transmit a full-header packet that can be used to construct a context to the receiving party multiple times within the same data stream according to certain regulations.
In the Compressed non-TCP compression technique, that is, the header compression technique used for the UDP/IP protocol, a full-header packet is transmitted at least once in each exponentially increasing period, which is called compression slow-start (CSS). According to the CSS method, if the full-header information is changed or a fresh header compression technique is applied, the transmission interval for the same full-header is shortened at an initial stage and then gradually increased thereafter.
FIG. 1 is a diagram showing a transmission intervals for transmitting full-header information in accordance with the CSS method. As shown, the transmission intervals for the full-header packet increase exponentially, and the number of compressed header packets transmitted between neighboring full-header packets (i.e., within each interval) is increased by 1, 2, 4, 8, . . . . The transmission interval is not infinitely increased but maintained at the same interval when it reaches a transmission interval threshold value, which is usually set by 256. For reference, the full-headers transmitted by the CSS method have the same CID (context identifier) value and generation number. That is, the full-header packet is transmitted in an exponential period for a packet stream with the same CID and generation value.
As previously discussed, if a header compression technique is used, the header size of the packet can be considerably reduced. Especially, in the case where a normal packet is transmitted through a radio interface, since the header of the packet is too big to be neglected compared with the payload size (a data portion of the packet), the header needs to be compressed.
FIG. 2 is a block diagram of a packet transmission system of the related art which uses a header compression technique. The system includes a header compression unit 10, provided in the PDCP layer, which compresses a header of data received from an upper layer under control of a header compression control unit 12. The full-header packet or the compressed header packet converted by the header compression unit 10 is delivered to the RLC layer through a data transmission unit 14. A buffer and transmission unit 16 of the RLC layer stores the full-header packet or the compressed header packet received from the data transmission unit 14 of the PDCP and/or transmits it to a receiving party.
Operation of the system will now be explained. First, in a case of using Compressed TCP as the header compression technique, a transmitting party first transmits a full-header packet for a packet stream to construct a context at a receiving party. One or more compressed headers are then transmitted indicating differences between successive packets.
If the full-header packet is not successfully transmitted from the transmitting party, since the context is not properly constructed at the receiving party, the receiving party fails to restore subsequently received compressed headers. In addition, even in the case where a compressed header packet is successfully transmitted, since the context of the receiving party is not properly updated, the following compressed headers cannot be restored, just as in the case where the full-header packet is lost. Since the damaged context can be recovered only by receiving a new full-header of a corresponding context, the receiving party transmits a context-state packet requesting transmission of a new full-header of the corresponding context from the transmitting party.
FIG. 3 shows a structure of a context-state packet in accordance with the related art. This packet includes a plurality of CID fields, each of which signifies one damaged context, that is, one damaged packet stream. Such a context-state packet is not used whenever one context is damaged, but is transmitted to the transmitting party when more than a predetermined number of contexts are damaged. In addition, transmission of the context-state packet itself from the receiving party to the transmitting party wastes radio resources, so that its frequency of use is limited in RFC 2507.
In transmitting packet data using the Compressed TCP header compression technique, if a full-header packet or a compressed header packet is lost, it takes a large amount of time to restore a corresponding context by the receiving party. Moreover, the transmitting party is not aware that the corresponding context has been damaged. Thus, the following compressed header packets are uselessly transmitted, which results in wasting radio resources.
FIG. 4 shows a structure of a compressed header used in a UDP/IP protocol. As previously discussed, in performing UDP/IP header compression, the generation value of corresponding header information as well as the CID value is used to discriminate packet streams. Thus, the compressed header only contains the CID field, the generation field, and the checksum field and as a result has a total length of about 4-5 octets.
In the compressed header of FIG. 4, if an 8 bit CID is used, CID(2) positioned at the third octet is not necessary. If a 16 bit CID is used, 8 bits are allocated to CID(1) and the other 8 bits are allocated to CID(2). Considering that the size of a full-header is 48 octets, it is noted that the same purpose can be achieved by transmitting a very small amount.
In transmitting packet data using the Compressed TCP header compression technique following the TCP/IP Header Compression Algorithm (RFC 2507 Compressed TCP), a full-header packet is transmitted at the first packet of a packet stream. The following packets are transmitted with compressed header containing the variance from previously transmitted headers of a packet stream. The context of the packet stream is continuously updated with the compressed header in the reference of previously received packet headers.
In transmitting packet data using another Compressed TCP header compression technique following the TCP/IP Header Compression Algorithm (RFC 2507 Compressed TCP nondelta), a full-header packet is transmitted at the first packet of a packet stream. The following packets are transmitted with compressed header containing the variance from previously transmitted full header of the packet stream. The context of the packet stream is continuously updated with the compressed header in the reference of previously received full header.
In transmitting packet data using UDP/IP Header Compression Algorithm (Compressed non-TCP, Compression Slow-Start, hereinafter referred to CSS), full-header packets are transmitted at the first packet and some of following packets of a packet stream in a predetermined rule. FIG. 5 is a flow chart of a related art method for transmitting a full-header packet and a compressed header packet according to the CSS method. In this figure, an INT (Interval) value indicates the number of compressed header packets that can be transmitted between two consecutively transmitted full-header packets, and a CNT (Count) value indicates the number of transmitted compressed header packets.
According to this method, a compressed header packet is transmitted, and when the CNT value and the INT value become the same, the full-header packet is transmitted instead of the compressed header packet. The INT value is updated at the time when the full-header is to be transmitted. When the INT value reaches a MaxINT, which corresponds to a transmission interval threshold value, the INT value is no longer increased and the MaxINT is maintained. The process is terminated when all data in a packet stream are transmitted or when the full-header information is changed. The transmission method will now be described in greater detail.
First, the minimum number (INT) of compressed header packets that can be transmitted between the full-header packets is set to an initial value of ‘1’.
When a header packet transmission operation is initiated, the full-header packet is first transmitted (S80), and then the CNT indicating the number of the transmitted compressed header packets is initialized to a value of ‘0 ’(CNT=0) (S81). Next, the compressed header packet is transmitted (S82) and then the CNT indicating the number of transmitted compressed header packets is increased by ‘1 ’(CNT=CNT+1) (S83).
Next, the INT value and the CNT value are compared (S84), and if the two values are different a compressed header packet is additionally transmitted and steps S82-S84 are repeatedly performed. If the two values are the same, it is checked whether the INT value is greater than the MaxINT (in the present invention, MaxINT=256) (S85). If the INT value is smaller than the MaxINT, steps S80-S85 are repeatedly performed while increasing the INT value by the unit of multiple of ‘2 ’(1, 2, 4, 8, 16, . . . , 256). If, however, the INT value is the same or greater than the MaxINT value, the INT value is no longer increased and the same transmission interval is maintained.
Transmitting full-header packets using the CSS method of the related art is advantageous in at least two respects. First, even if the full-header packet is lost during transmission, the compressed header can be recovered by using the next-transmitted full-header packet. Second, in the case where the same packet is broadcast to several users through a multicast technique, even if a new user is connected in the course of broadcasting, the new user can receive data normally after receiving the full-header packet (e.g., the new user can receive compressed packets and then recover them based on information in a next-transmitted full-header packet). These advantages lend a measure of stability to the system.
In spite of these advantages, the CSS method of the related art has a number of drawbacks. For example, since the full-header is much larger than the compressed header, repeated transmission of a considerable number of full-header packets within a same data stream substantially degrades transmission efficiency. This is especially true if the full-header packet is successfully transmitted at the initial stage. Under these circumstances, the related art method will continue to intermittently transmit full-header packets in the data system even though the initial full-header packet was successfully transmitted. As will become more apparent below, the Inventors of the present invention have determined that every full-header packet transmitted after an initial full-header packet has been successfully received may be considered to be an unnecessarily transmitted one.
The Compressed TCP header compression technique following the TCP/IP Header Compression Algorithm of the related art also has a number of drawbacks. For example, the context of a packet of compressed header is recovered in the reference of the full-header directly or indirectly. If, one of the headers of a packet in a stream is not received successfully or the full-header is not received successfully, several packets following that packet could not be recovered for a time being. That is, the transmission of packet data using the Compressed TCP header compression technique, if a full-header packet or a compressed header packet is lost, it takes a large amount of time to restore a corresponding context by the receiving party. Moreover, the transmitting party is not aware that the corresponding context has been damaged. Thus, the following compressed header packets are uselessly transmitted, which results in wasting radio resources. If the receiver transmits the request of sending a full-header packet to the transmitter immediately, the traffic load for the request might be a burden to the radio channel.